Attached (External) Subnets #911
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
FelixMcFelix
force-pushed
the
attached-subnets-mvp
branch
7 times, most recently
from
374d344 to
a832697
Compare
FelixMcFelix
force-pushed
the
attached-subnets-mvp
branch
from
a832697 to
5dc70c8
Compare
This PR reworks certain aspects of how NAT and gateway layers are constructed to enable attached (external) subnets to function. The primary aim here is that traffic to/from these subnets (owned by the host) do not undergo NAT, and bypass spoof detection as transit IPs would. A few wider changes have been necessary to ensure that these can be attached/detached without breaking any existing transit IPs, and to ensure that traffic originated from an external subnet cannot be directed towards a private VPC recipient.
FelixMcFelix
force-pushed
the
attached-subnets-mvp
branch
from
5dc70c8 to
2e7cf69
Compare
FelixMcFelix
commented
Jan 6, 2026
| use opte_api::Protocol; | ||
|
|
||
| pub trait Ip: Into<super::IpAddr> { | ||
| pub trait Ip: Into<super::IpAddr> + Send + Sync { |
Collaborator
Author
There was a problem hiding this comment.
Followup from #883 -- this moves the Send + Sync bounds up so that we don't need to explicitly specify them in as many spots.
Comment on lines
+563
to
+568
| pub fn attach_subnet( | ||
| port: &Port<VpcNetwork>, | ||
| inet_gw_map: Option<&InternetGatewayMap>, | ||
| vpc_mappings: &Arc<VpcMappings>, | ||
| req: AttachSubnetReq, | ||
| ) -> Result<(), OpteError> { |
Collaborator
Author
There was a problem hiding this comment.
I had a bit of uncertainty as to whether this and detach_subnet should live here, gateway, or some other module since the feature crosses multiple layers.
bnaecker
reviewed
Jan 8, 2026
Contributor
bnaecker
left a comment
bnaecker
left a comment
There was a problem hiding this comment.
I've not looked through the entire PR yet, but this seems solid. Nice interface for attaching subnets, and some helpful cleanup along the way. Thanks!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR reworks certain aspects of how NAT and gateway layers are constructed to enable attached (external) subnets to function. The primary aim here is that traffic to/from these subnets (owned by the host) do not undergo NAT, and bypass spoof detection as transit IPs would. A few wider changes have been necessary to ensure that these can be attached/detached without breaking any existing transit IPs, and to ensure that traffic originated from an external subnet cannot be directed towards a private VPC recipient.
VpcCfgrather than working directly on the port's ruleset. This also gives us the opportunity to set these on port create rather than using a followup ioctl.DhcpCfginVpcCfgnow.VpcCfginXdeDevand the port itself seemed... misleading, at best. When XDE needs that, we now reach throughport.network().StatefulActions should never have had mutable access to a packet'sActionMeta(the string-to-string map), because they may never be rerun after an LFT is created on subsequent slowpath walks. It is now up to the generatedActionDescs to update metadata -- this trait's role is similar toStaticAction, which is allowed mutable access to this metadata.ActionMetaergonomics to make this easier to express and implement.As far as the control plane is concerned, it should need to only:
Instance(<name>)target (in turn resolved to an IP target when reifying rules for the port, as happens with instance targets today).Answers the functional dataplane requirements of #890. Closes #703.